Skunkware 5

home *** CD-ROM | disk | FTP | other *** search

/ Skunkware 5 / Skunkware 5.iso / src / Tools / lsof_3.37 / 00FAQ < prev next >

Wrap

Text File | 1995-08-01 | 32.4 KB | 904 lines

Frequently Asked Questions about lsof ********************************************************************** | The latest release of lsof is always available via anonymous ftp | | from vic.cc.purdue.edu. Look in pub/lsof.README for its location. | ********************************************************************** ______________________________________________________________________ This file contains frequently asked questions about lsof and answers to them. Vic Abell July 26, 1995 ______________________________________________________________________ Table of Contents: 1.0 General Concepts 1.1 Lsof -- what is it? 1.2 Where do I get lsof? 1.2.1 Are there mirror sites? 1.2.2 Are lsof executables available? 1.2.3 Why can't I extract the lsof tar files? 2.0 Lsof Ports 2.1 What ports exist? 2.2 What about a new port? 2.2.1 User-contributed Ports 2.2.2 Dell SVR4 2.3 Why isn't there an AT&T SVR4 port? 3.0 Lsof Problems 3.1 Why doesn't lsof report full path names? 3.2 Does lsof have security problems? 3.3 Will lsof show remove hosts using files via NFS? 3.4 My Sun gcc-compiled lsof doesn't work -- why? 3.4.1 How can I make lsof compile with gcc under Solaris 2.4? 3.4.2 How can I make lsof compile with gcc under SunOS 4.1.x? 3.4.3 Why does the Solaris SunPRO cc complain about system header files? 3.5 How do I compile lsof on a previous revision of Pyramid DC/OSx? 3.6 AIX Problems 3.6.1 How can I compile a working lsof for AIX 4.1? 3.6.2 What is the Stale Segment ID bug and why is -X needed? 3.6.2.1 Stale Segment ID APAR 3.7 Why doesn't lsof display open IRIX 5.3 XFS files properly? 3.8 Where is the IRIX 5.3 <sys/vnode.h>? 3.9 Why does an HP-UX lsof compilation get ``unknown "O" option?'' 3.10 Why doesn't a NetBSD 1.0A binary run on my 1.0A system? 3.11 Why does an asterisk (`*') precede some inode numbers? 4.0 Lsof Features 4.1 Why doesn't lsof doesn't report on /proc entries on my system? 4.2 How do I disable the device cache file feature or alter it's behavior? 5.0 Linux 5.1 Why doesn't lsof work (or even compile) on my Linux system? 5.2 Why does lsof complain about /dev/kmem? 5.3 Why can't lsof find kernel addresses? 5.4 Where is /zSystem.map (or /System.map)? Why doesn't it match my kernel? ______________________________________________________________________ 1.0 General Concepts 1.1 Lsof -- what is it? Lsof is a Unix-specific tool. It's name stands for LiSt Open Files, and it does just that. It lists information about files that are open by the processes running on a Unix system. See the lsof man page, the 00DIST file, and the 00README file of the lsof distribution for more information. 1.2 Where do I get lsof? Lsof is available via anonymous ftp from vic.cc.purdue.edu (128.210.15.16). Look in the pub/tools/unix/lsof sub- directory. Compressed and gzip'd tar files with PGP certificates are available. 1.2.1 Are there mirror sites? The lsof distribution is currently mirrored at: coast.cs.purdue.edu pub/tools/unix/lsof ftp.auscert.org.au /pub/mirrors/vic.cc.purdue.edu/lsof/* ftp.cert.dfn.de /pub/tools/misc ftp.cs.columbia.edu archives/lsof/ ftp.fu-berlin.de pub/unix/tools/lsof ftp.gre.ac.uk pub/tools/lsof ftp.rge.com /pub/lsof ftp.sterling.com /admin-tools/lsof ftp.sunet.se pub/unix/admin/lsof ftp.tau.ac.il /pub/sources/admin wuarchive.wustl.edu /packages/security/lsof 1.2.2 Are lsof executables available? Some lsof executables are available in the subdirectory tree pub/tools/unix/lsof/binaries These are neither guaranteed to be current nor cover every dialect and machine architecture. I don't recommend you use pre-compiled lsof binaries; I recommend you obtain the sources and build your own binary. Even if you're a Sun user without a SunPRO C compiler, you can use gcc to compile lsof. If you must use a binary file, please be conscious of the security implications in using an executable of unknown origin. The lsof binaries are accompanied by PGP certificates. Please use them! 1.2.3 Why can't I extract the lsof tar files? I have had a report from a Solaris user that he was unable to extract the lsof distribution file under Solaris 2.3 or 2.4. I was able to duplicate his report. When I upgraded tar on my NeXT cube (where I generate the lsof distribution) to GNU tar 1.11.2 (plus some local fixes), I could no longer duplicate the problem. The Solaris user still reports that he can extract the GNU- tar-1.11.2-built archive, but gets warning messages from tar. I get no warning messages, so we jointly suspect that it's possible some Sun patch has made our two tar programs somewhat incompatible. If you have problems extracting the lsof distribution, please try GNU tar 1.11.2 or later. If that fails, contact me. 2.0 Lsof Ports 2.1 What ports exist? The pub/lsof.README file carries the latest port information: AIX 3.2.[45], 4.1, 4.1.1, and IBM RISC/System 6000 4.1.2 DC/OSx 1.1 Pyramid ES, Nile, and S EP/IX 2.1.1 CDC 4680 FreeBSD 1.1.5.1, 2.0, and Intel-based systems 2.0.5 HP-UX 8.x, 9.x, 10 HP IRIX 4.0.5, 5.2, 5.3, and 6.0 SGI Linux through 1.2.11 Intel-based systems NetBSD 1.0 and 1.0A Intel and SPARC-based systems NEXTSTEP 2.1 and 3.[0123] all NEXTSTEP architectures Novell UnixWare 1.1, 1.1.1, Intel-based systems and 1.1.2 OSF/1 1.3, 2.0, 3.0, and 3.2 DEC Alpha RISC/os 4.52 MIPS R2000-based systems SCO OpenDesktop, OpenServer Intel-based systems 1.1, 3.0, and 5.0 Sequent Dynix 3.0.12 Sequent Symmetry Sequent PTX 2.1.[156] and Sequent systems 4.0.[23] Solaris 2.[1234] Sun 4 and i86pc SunOS 4.1.3 Sun 3 and 4 Ultrix 2.2, 4.2, 4.3, and 4.4 DEC RISC and VAX V/88 R32V3, R40V4.2, and Motorola M88K R40V4.3 2.2 What about a new port? The 00PORTING file in the distribution gives hints on doing a port. (An lsof port is not for the faint of heart.) It has been done -- witness Anthony Shortland's Pyramid DC/OSx port. He started with the Novell UnixWare port and needed to make but a few changes; you might consider starting there, too, if you want to try your hand at porting lsof to a new Unix dialect. I will consider doing a port in exchange for permanent access to a test host. I require permanent access so I can test new lsof revisions, because I will not offer distributions of dialect ports I cannot upgrade and test. 2.2.1 User-contributed Ports Sometimes I receive contributions of ports of lsof to systems where I can't test future revisions of lsof. Hence, I don't incorporate these contributions into my lsof distribution. However, I do make these contributions available in the directory: pub/tools/unix/lsof/contrib on my ftp server, vic.cc.purdue.edu. Consult the 00INDEX file in the contrib/ directory for a list of the available contributions. 2.2.2 Dell SVR4 There is no lsof port for Dell SVR4. However, Kevin Kadow <kadokev@rci.ripco.com reports that he has been able to use the UnixWare version of lsof under Dell SVR4. Kevin did not compile lsof from sources, but used the binary made available through the Novell mail server (see 00README for details). A UnixWare binary is also available via anonymous ftp from vic.cc.purdue.edu in pub/tools/unix/lsof/binaries/novell. 2.3 Why isn't there an AT&T SVR4 port? I haven't produced an AT&T SVR4 port because I haven't seen a Unix dialect that is strictly limited to the AT&T System V, Release 4 source code. Every one I have seen is a derivative with vendor additions. The vendor additions are significant to lsof because they affect the internal kernel structures with which lsof does business. While some vendor derivatives of SVR4 are similar, each one I have encounted so far has been different enough from its siblings to require special source code. If you're interested in an SVR4 version of lsof, here are some existing ports you can consider: DC/OSx 1.1 EP/IX 2.1.1 IRIX 5.2, 5.3, and 6.0 Sequent PTX 4.0.[23] Solaris 2.[1234] UnixWare 1.1, 1.1.1, and 1.1.2 V/88 R40V4.2 and R40V4.3 3.0 Lsof Problems 3.1 Why doesn't lsof report full path names? Lsof reports full path names in two, limited cases: 1) some systems, e.g., some IRIX and SunOS versions, contain full directory path names in their user structure, so lsof reports those; or 2) lsof reports the full path name when it is specified as a search argument for open files that match it. As of revision 3.19 lsof reports some path name components (e.g., the proc.h component of /usr/include/sys/proc.h) for these dialects: DEC OSF/1 2.0, 3.0, and 3.2 Dynix (Purdue 3.0.12) EP/IX 2.1.1 FreeBSD 1.1.5.1, 2.0, and 2.0.5 HP-UX 9.01 Motorola V/88 R40V4.2 (but not R32V3) NetBSD 1.0 and 1.0A NEXTSTEP 3.1 RISC/os 4.52 SGI IRIX 5.3 Solaris 2.[34] SunOS 4.1.[23] Ultrix 2.2, 4.2, and 4.3 (last component only) (For an up-to-date list of dialects with path name component reporting consult the KERNEL NAME CACHE section of the lsof man page.) Lsof obtains the components from the kernel's name cache. Since the size of the cache is limited and the cache is in constant flux, it does not always contain the names of all components in an open file's path; sometimes it contains none of them. Lsof reports the file system directory name and whatever components of the file's path it finds in the cache, starting with the last component and working backwards through the directories that contain it. If lsof finds no path components, lsof reports the file system device name instead. When lsof does report some path components in the NAME column, it prefixes them with the file system directory name, followed by " -- ", followed by the components -- e.g., /usr -- sys/path.h for /usr/include/sys/path.h. Lsof can't obtain path name components from the kernel name caches of the following dialects: AIX The knlist() function won't return cache addresses -- some IBM wisdom to "protect" their customers. Linux It doesn't seem to have a kernel name cache. Motorola V/88 It doesn't have a unified name cache. R32V3 Novell UnixWare I don't have a test system. Pyramid DC/OSx I don't have a test system. SCO OpenDesktop It doesn't have a unified name cache. OpenServer SGI IRIX 4.0.5H I saw no unified name cache in the header files. SGI IRIX 5.2 and The name cache is not visible to 6.0 application programs. Novell UnixWare I don't have a test system. The effort of reporting full path names is expensive. No Unix kernel records full path names in the structures it records about open files; instead, kernels convert path names to device and inode number doublets and use them for subsequent file references once files have been opened. To convert the device and inode number doublet into a complete path name, lsof would have to start at the root node (root directory) of the file system on which the inode resides, and search every branch for the inode, building possible path names along the way. That would be a time consuming operation and require access to the raw disk device (usually implying setuid(root) permission). If the prospect of that much disk activity doesn't concern you, think about the cost when the device is NFS-mounted. 3.2 Does lsof have security problems? I don't think so. However, lsof does usually have setgid(kmem) permission or the equivalent. In some SYSV systems it has setuid(root) permission to access /proc file system entries. Any program that has setgid or setuid permission should always be regarded suspiciously. The setgid or setuid power leads to a potential security problem. It could allow lsof to read a kernel name list or memory file via the -c and -k options. To circumvent this problem lsof (revisions 3.07 and above) uses access(2) to determine its real UID's authority to read files declared with -c and -k. My thanks to Tim Ramsey <tar@ksu.ksu.edu> for identifying this problem. The device cache file (typically /tmp/.lsof_dev_cache) has 0666 modes. However, even when lsof runs setuid(root), it makes sure the file's ownerships are changed to that of the real user and group. In addition, lsof checks the file carefully before using it (see section 4.2 for a description of the checks); discards the file if it fails the scrutiny; complains about the condition of the file; then rebuilds the file. 3.3 Will lsof show remote hosts using files via NFS? No. Remember, lsof displays open files for the processes of the host on which it runs. If the host on which lsof is running is an NFS server, the remote NFS client processes that are accessing files on the server leave no process records on the server for lsof to examine. 3.4 My Sun gcc-compiled lsof doesn't work -- why? Gcc can be used to build lsof successfully. However, an improperly installed Sun gcc compiler will usually not produce a working lsof. Under SunOS 4.1.x this may happen when the gcc compiler is copied from one Sun architecture -- e.g., from a sun4m to a sun4. The problem comes from the copying of the special #include header files that gcc "fixes" during installation to circumvent ANSI-C conflicts, especially on #else and #endif pre-processor declarations. Some of the "fixed" header files declare kernel structures whose length varies with architecture type. In particular, the size of the user structure (<sys/user.h>) changes with architecture type, and, since lsof gets command name and file pointers from that structure, can cause lsof to malfunction when its length is incorrect. These architecture-related structure differences changes do not seem to occur under Solaris. Instead, the more common reason a gcc-compiled lsof doesn't work there is that the special gcc header files were not updated during the change from one version Solaris to the next -- e.g., from 2.3 to 2.4. If your Sun gcc-compiled lsof doesn't report anything, check that the gcc "fixincludes" step was run on the system where you're using gcc to compile lsof. 3.4.1 How can I make lsof compile with gcc under Solaris 2.4? Presuming your gcc-specific header files are wrong for Solaris, edit the lsof Configure-generated Makefile and change: CFGF= -Dsolaris=20400 to CFGF= -Dsolaris=20400 -D__STDC__=0 -I/usr/include This is only a temporary work-around. You really should rerun gcc's fixincludes scripts to update your gcc-specific header files. 3.4.2 How can I make lsof compile with gcc under SunOS 4.1.x? Presuming your gcc-specific header files are wrong for SunOS 4.1.x, edit the lsof Configure-generated Makefile and change: CFGF= -ansi -DSUNOSV=40103 to CFGF= -DSUNOSV=40103 -I/usr/include This is only a temporary work-around. You really should rerun gcc's fixincludes scripts to update your gcc-specific header files. 3.4.3 Why does the Solaris SunPRO cc complain about system header files? You're probably trying to use /usr/ucb/cc if you get compiler complaints like: cc -O -DCANDOCHILD -Dsun -Dsolaris=20300 ... "/usr/include/sys/machsig.h", line 81: macro BUS_OBJERR redefines previous macro at "/usr/ucbinclude/sys/signal.h", line 444 Note the reference to "/usr/ucbinclude/sys/signal.h". It reveals that the BSD Compatibility Package C compiler is in use. Lsof requires the ANSI C version of the Solaris C compiler, usually found in /usr/opt/bin/cc or /opt/SUNWspro/bin/cc. Try adding a CC string to the lsof Makefile that points to the Sun ANSI C version if the SunPRO C compiler -- e.g., CC= /usr/opt/bin/cc or CC= /opt/SUNWspro/bin/cc. 3.5 How do I compile lsof on a previous version of Pyramid DC/OSx? If you are running a version of Pyramid DC/OSx earlier than the ones on which lsof was developed -- 1.1-94c079 or 1.1-94d079 -- you may find that your compiler complains that the mntent.h and mnttab.h header files are missing. If you can "borrow" those header files from a later version of DC/OSx, you may be able to compile and use lsof. Robert Vernon <bob@pyramid.com.au> reports he used this strategy successfully on an ES series machine, running DC/OSx 1.1-93c063. 3.6 AIX Problems 3.6.1 How can I compile a working lsof for AIX 4.1? If you have updated your AIX system to 4.1, but haven't updated your xlc compiler, the lsof you compile may not work. This is caused by the new -qlonglong or -qlongdouble default option to xlc; it causes the _LONG_LONG symbol to be defined; _LONG_LONG causes a slight change in the size of the user structure from <sys/user.h>; and the size of the user structure is important to lsof when it issues the undocumented getuser() call, because getuser() fails when the size of the user structure is stated incorrectly. You can tell if your compiler has been updated by using the xlc command without options. Called that way xlc will show you the options it supports. If -qlonglong or -qlongdouble aren't among them, your compiler is not sufficiently up to date. There is an easy work-around: add -D_LONG_LONG to the CFGF string in the Makefile. Change CFGF= -D_AIXV=4100 to CFGF= -D_AIXV=4100 -D_LONG_LONG 3.6.2 What is the Stale Segment ID bug and why is -X needed? Kevin Ruderman <rudi@acs.bu.edu> reports that he has been informed by IBM that processes using the AIX 3.2.x and 4.1[.x] kernel's readx() function can cause other AIX processes to hang because of what appears to be file system corruption. This failure, known as the Stale Segment ID bug, is caused by an error in the AIX kernel's journalled segment memory handler that causes the kernel's dir_search() function erroneously to believe directory entries contain zeroes. The process using the readx() call need not be doing anything wrong. Usually the system must be under such heavy load that the segment ID being used in the readx() call has been freed and then reallocated to another process since it was obtained from kernel memory. Lsof uses the readx() function to access library entry structures, based on the segment ID it finds in the proc structure of a process. Since IBM has indicated they will not fix the kernel bug in AIX 3.2.x or 4.1[.x] and may not fix it until some version of 4.2, I've added an AIX-specific option to lsof that controls its use of the readx() function. By default lsof readx() use is disabled; specifying the ``-X'' option enables readx() use. When readx() use is disabled, lsof will report that in the NAME column for AIX 3.2.x and 4.1 text and loader references whose loader entry structures must be obtained using readx(). (Lsof won't report anything for AIX 4.1.x text and loader references when readx() use is disabled.) If lsof encounters an AIX 3.2.x or 4.1 loader entry that it can't read because readx() use is disabled, it stops reporting loader entry information, since loader entries are linked by pointer elements. If you want to change the default readx() behavior of AIX lsof, change the HASXOPT and HASXOPT_VALUE definitions in dialects/aix/machine.h. You can also use these definitions to enable or disable readx() use permanently -- consult the comments in machine.h. You may want to disable readx() use permanently if you plan to make lsof publicly executable. I have never seen lsof cause this problem, but I believe there is some chance it could, given the right circumstances. 3.6.2.1 Stale Segment ID APAR Here are the details of the Stale Segment ID bug and IBM's response, provided by Kevin Ruderman <rudi@acs.bu.edu>. AIX V3 APAR=ix49183 user process hangs forever in kernel due to file system corruption STAT=closed prs TID=tx2527 ISEV=2 SEV=2 (A "closed prs" is one closed with a Permanent ReStriction.) RCOMP=575603001 aix v3 for rs/6 RREL=r320 AIX V4 (internal defect, no apar #) prefix p name 175671 abstract KERMP: loop for ever in dir_search() Problem description: 1. Some user application -- e.g., lsof -- gets the segment ID (SID) for the process private segment of a target process from the process table. 2. The target process exits, deleting the process private segment. 3. The SID is reallocated for use as a persistent segment. 4. The user application runs again and tries to read the user area structure from /dev/mem, using the SID it read from the process table. 5. The loads done by the driver for /dev/mem cause faults in the directory; new blocks are allocated; the size changed; and zero pages created. 6. The next application that looks for a file in the affected directory hangs in the kernel's dir_search() function because of the zero pages. This occurs because the kernel's dir_search() function loops through the variable length entries one at a time, moving from one to the next by adding the length of the current entry to its address to get the address of the next entry. This process should end when the current pointer passes the end of the known directory length. However, while the directory length has increased, the entry length data has not, so when dir_search() reaches the zero pages, it loops forever, adding a length of zero to the current pointer, never passing the end of the directory length. The application process is hung; it can't be killed or stopped. IBM has closed the problem with a PRS code (Permanent ReStriction) under AIX Version 3 and has targeted a fix for AIX V4.2. 3.7 Why doesn't lsof display open IRIX 5.3 XFS files properly? Dave Olson <olson@anchor.engr.sgi.com> who provided the IRIX 5.3 changes to lsof, says he was unable to include support for the new XFS file system, because of completely different in-core data structures for XFS inodes. 3.8 Where is the IRIX 5.3 <sys/vnode.h>? According to Dave Olson of SGI, <sys/vnode.h> is shipped with IRIX 5.3 in eoe1.sw.unix. However, during the XFS installation or the installation of some XFS patch, it is installed a second time. (So far no problem.) However, if XFS or the XFS patch is removed, <sys/vnode.h> is removed, too. Some possible solutions: 1) copy <sys/vnode.h> manually from an IRIX 5.3 source where it still exists; or 2) mount the IRIX 5.3 CDROM and type: # inst -a -f /CDROM/dist -I eoe.sw.unix -Y /usr/include/sys/vnode.h The second solution was suggested by John R. Vanderpool <fish@daacdev1.stx.com>. 3.9 Why does an HP-UX lsof compilation get ``unknown "O" option?'' If you only have the standard HP-UX C compiler and haven't purchased and installed the optional one, when you try to compile lsof with the Makefile that "Configure hpux" produces, you'll get the warning message: cc: error 422: unknown option "O" ignored. The HP-UX cc(1) man page says this: "Options Note that in the following list, the cc and c89 options -A , -G , -g , -O , -p , -v , -y , +z , and +Z are not supported by the C compiler provided as part of the standard HP-UX operating system. They are supported by the C compiler sold as an optional separate product." If you can't install the "optional separate product," you can get rid of the warning message by editing the Makefile and removing the "-O" option from the DEBUG string -- i.e., change DEBUG= -O -DCANDOCHILD to DEBUG= -DCANDOCHILD 3.10 Why doesn't a NetBSD 1.0A binary run on my 1.0A system? Apparently NetBSD uname output isn't always sufficient to identify the system on which a given lsof binary will run. I've had trouble on an Intel system, identified as 1.0A before and after it was updated. A binary generated on the earlier instance wouldn't run on the later one. If you get one of the pre-compiled NetBSD binaries (I don't recommend it.), and it won't run, try building your own binary from the sources. 3.11 Why does an asterisk (`*') precede some inode numbers? An asterisk (`*') prefix on an inode number indicates the number was too large for the output field. Typically lsof reserves six digits for the inode number field. If the inode number is larger than that, lsof prints an asterisk and the last five digits of the inode number. If you have a system where inode numbers are usually larger than six digits, please let me know. There are two other things you can consider: 1. You can change the source code to print a larger inode number field -- look at the print_file() function in dfile.c. The print_file() function may come from common/prtf.frag for many dialects; check Mksrc and dfile.c in the dialect sub-directory to see if print_file() comes from prtf.frag. 2. You can specify field output (with -F, -f, and -0) and post-process the field output to display larger inode numbers. The sample awk and Perl field listing scripts do that. 3.12 Why does the offset have ``0t' and ``0x'' prefixes? The offset value that appears in the SIZE/OFF column has ``0t' and ``0x'' prefixes to distinguish it from size values that may appear in the same column. If the offset value is less than 100,000,000, it appears in decimal with a ``0t' prefix; over 99,999,999, in hexadecimal with a ``0x'' prefix. A decimal offset is handy, for example, when tracking the progress of an outbound ftp transfer. When lsof reports on the ftp process, it will report the size of the file being sent with its open descriptor; it will report the progress of the transfer via the offset of the outbound open ftp data socket descriptor. 4.0 Lsof Features 4.1 Why doesn't lsof doesn't report on /proc entries on my system? /proc file system support is generally available only for BSD, OSF, and SYSV R4 dialects. It's also available for Linux. Even on some SYSV R4 dialects I encountered many problems while trying to incorporate /proc file system support. The chief problem is that some vendors don't distribute the header file that describes the /proc file system node -- usually called prdata.h. I wasn't able to figure out how to provide /proc file system support under EP/IX 2.1.1 for the CDC 4680, because of environment conflicts. Lsof compiles in the svr3 environment, but some of the functions and header files it needs for /proc file system support come from the svr4 environment. I couldn't figure out how to mix the two. 4.2 How do I disable the device cache file feature or alter it's behavior? To disable the device cache file feature for a dialect, remove the HASDCACHE definition from the machine.h file of the dialect's machine.h header file. You can also use HASDCACHE to change the default location of the device cache file. If you're worried about the presence of the mode 0666 device cache file in your /tmp, consider these checks that lsof makes on the file before using it: 1. The device cache file's modes must be 0666 and its size non-zero. 2. The device cache files' mtime must be greater than the mtime and ctime of the device directory (usually /dev). 3. There must be a correctly formatted section count line at the beginning of the file. 4. Each section must have a header line with a count that properly numbers the lines in the section. Legal sections are device, clone, pseudo-device, and CRC. 5. The lines of a section must have the proper format. 6. All lines are included in a 16 bit CRC, and it is recorded in a non-checksummed section line at the end of the file. 7. The checksum computed when the file is read must match the checksum recorded when the file was written. 8. The checksum section line must be followed by end-of-information. 9. Lsof must be able to get matching results from stat(2) on a randomly chosen entry of the device section. 10. Lsof changes the file's ownerships to the caller's effective IDs after creating it. 5.0 Linux 5.1 Why doesn't lsof work on my Linux system? I have produced ports of lsof to two Linux versions, 1.0.9 and 1.1.47, the Yggdrasil Plug-and-Play Linux Fall '94 release. Lsof may not work under other Linux versions, simply because of the pace of Linux development. Hendrik G. Seliger <hank@Blimp.automat.uni-essen.de> reports that lsof compiles and seems to work under Linux 1.1.61. He used the linux1147 Configure abbreviation. Marty Leisner <leisner@sdsp.mc.xerox.com> reports that lsof compiles and seems to work under Lunix 1.1.64. He used the linux1147 Configure abbreviation, too. Marty later reports that lsof 3.25 compiles and works under Linux 1.2.5, using the linux Configure abbreviation (new at lsof 3.20); and lsof 3.29 compiles and works under Linux 1.2.8. Michael Shields <shields@tembel.org> and I have tested lsof 3.32 under Linux 1.2.10. Lsof is a complicated application. It probes kernel memory and looks at kernel structures. Linux kernel development tends to affect both those items. I know, for example, that kernel memory structures changed between 1.0.9 and 1.1.47, because I had to adjust lsof for differences in task structure elements between the two Linux versions. If lsof doesn't even compile on your Linux system, you may be using a version of Linux whose header files differ from the ones I used. Or you may not have installed /usr/src/linux, and lsof can't find header files that it needs from that directory. 5.2 Why does lsof complain about /dev/kmem? Lsof reads kernel information via /dev/kmem. If you get this error message: lsof: can't open /dev/kmem then the permissions on /dev/kmem or the authority you have when using lsof aren't powerful enough to allow lsof to read from it. Often /dev/kmem is owned by the kmem or system group and has group read permission, so lsof needs to run setgid kmem or system, or the login that runs it must be in the kmem or system group (that's the way I test lsof). So, become the super user and: either $ chgrp kmem lsof or $ chgrp system lsof and $ chmod 2755 lsof 5.3 Why can't lsof find kernel addresses? The failure to read kernel addresses usually is accompanied by error messages like: lsof: can't read kernel name list from <file_name> lsof: missing kernel high memory definition lsof: missing kernel memory map definition lsof: missing kernel memory start definition lsof: no _task kernel definition lsof: can't read memory parameters These messages describe failures in obtaining addresses for the symbols that identify kernel structures lsof wants to read. Lsof obtains kernel symbol addresses from the /zSystem.map file -- that will usually be the <file_name> argument in the "can't read kernel name list from" error message. You might not have that file, or it might not be in that place (See 5.4.) If you encounter kernel address access errors and find a strategy that works, please let me know and I'll add its description to this file. 5.3 Why does lsof have trouble reading kernel structures? On my development systems with Linux 1.0.9 and 1.1.47 I found I could read all relevant kernel structures via /dev/kmem. I suspect later Linux versions may require that lsof use other memory access techniques, but I have no system on which to test this hunch. 5.4 Where is /zSystem.map (or /System.map)? Why doesn't it match my kernel? Lsof uses the system map file -- /zSystem.map or /System.map -- to locate addresses of the symbols for kernel information it needs to read. Without this file, lsof cannot function. The system map file is installed automatically when you use the kernel Makefile to install a new kernel. If you made a new kernel and installed it manually, you may have forgotten to install the system map file that matches it. The Configure script tries to determine which system map file to use -- /zSystem.map or /System.map -- when it processes the linux abbreviation. If /zSystem.map exists, the Configure script lets lsof default to using it; if /zSystem.map doesn't exist, but /System.map does, the Configure script defines a symbol that causes lsof to use it; if neither exists, Configure issues a warning and lets lsof try to use /zSystem.map. Garner Halloran <kheldar@felix.cc.gatech.edu> helped me sort this out. Lsof revisons 3.35 and above have code, courtesy of Marty Leisner <leisner@sdsp.mc.xerox.com>, that tries to determine if the system map file and the booted kernel are a matched set. The code compares the symbol names and addresses from the system map file to the symbol names and addresses from /proc/ksyms. If any matching pair of names has different addresses, lsof complains and stops -- e.g., $ lsof -k ./XXX lsof: kernel symbol address mismatch: do_munmap /proc/ksyms value=0x122018; ./XXX value=0x12201a There were 161 additional mismatches. ./XXX and the booted kernel may not be a matched set.